Manual Test Cases in the Agentic Era: The Baseline AI Agents Need

AI agents are changing the economics of software development. Source code can now be generated, refactored, and replaced faster than it can be reviewed. Automated tests are generated as side artifacts of the code production, which raises the question of testing AI-generated code before it reaches production. This acceleration is valuable. But it creates a new governance problem:

When the same development process produces both the implementation and the evidence that the implementation is correct, who independently verifies the intended behavior?

When Tests Become Derivatives of the Code

Traditionally, automated tests were expected to act as an independent auditor of software. They described expected behavior and warned the team when an implementation violated it.
In an agentic workflow, that independence can quietly disappear. A development agent implements a feature, runs the test suite, encounters failures, and updates the tests until everything passes. The final result looks healthy: the code compiles, the pipeline is green, and the automated tests confirm what the system does. However, those tests may no longer verify what the system should do. They may simply document and reinforce what the latest implementation already does.
This is particularly dangerous when agents infer expected behavior from the source code itself. If the implementation contains a misunderstanding, the generated tests can reproduce the same misunderstanding. The test suite then becomes an artifact of the code rather than an independent source of verification. A passing test suite is valuable evidence. But only when its expectations come from a source that is independent of the implementation.

The E2E Maintenance Warning

Teams often notice this problem indirectly. A development agent starts spending ten or more minutes during every coding session to repair end-to-end tests. Assertions are rewritten, selectors are replaced, snapshots are regenerated, and expected results are adjusted. Tools for self-healing test automation absorb part of that work, but they repair the mechanics, not the expectation.
Some maintenance is legitimate. Interfaces change, workflows evolve, and automation must follow approved product decisions. However, persistent repair work is a warning signal. It may indicate the following:

• Expected behavior is not clearly defined.
• Tests are coupled too closely to implementation details.
• Agents cannot distinguish an intentional product change from a regression.
• Automated checks are being modified to accommodate the code.
• The team lacks an independent behavioral baseline.

At this point, organizations usually make one of two choices. They either keep repairing an increasingly unstable E2E suite or reduce their reliance on E2E testing because it appears too expensive. Neither option addresses the underlying problem. The missing component is not more automation. It is a stable, reviewable definition of expected behavior.

Manual Test Cases as Executable Intent

Manual test cases can provide that definition.
In this context, “manual” does not necessarily mean that a person must execute every test by hand during every release. It means that the test case is expressed independently of automation code: in plain language, Markdown, Gherkin, or another format that product, engineering, and QA stakeholders can review. A useful manual test case describes:

• The business scenario.
• Relevant preconditions.
• The user’s actions.
• The expected outcome.
• Important negative and boundary conditions.
• The requirement or acceptance criterion it verifies.

Because these cases are readable without understanding the test framework, they create a shared contract among product managers, developers, QA engineers, and AI agents. They can be reviewed before implementation, validated with stakeholders, versioned alongside other delivery artifacts, and used as the input for automation.
Changing a Markdown scenario is also substantially cheaper than repeatedly debugging a complex E2E test. The team can settle the intended behavior first and update the automation only after the behavioral change has been approved.

A Better Agentic Quality Workflow

A more reliable workflow separates implementation, behavioral specification, and automated verification. In practice, this means separate agents for writing cases and for automating them:

1. Requirements define the intended outcome. Product requirements and acceptance criteria explain why the change exists and what value it should deliver.
2. Manual test cases make the behavior concrete. QA translates the intent into reviewable scenarios, including negative paths, boundary conditions, permissions, data states, and regression risks.
3. The development agent implements the behavior. It may propose changes to the manual cases when it discovers ambiguity or a legitimate product impact, but it should not silently redefine them.
4. A dedicated automation agent implements the E2E checks. Its source of truth is the approved test case, not merely the current source code or rendered interface.
5. A requirement-review agent audits behavioral changes. When a manual case is changed, this agent checks whether the modification is supported by an approved requirement and whether it conflicts with existing behavior.

This separation prevents one agent from changing the implementation, redefining the expectation, and approving the result within the same feedback loop.

Manual Test Cases as a Governed Source of Truth

Manual test cases can serve as a clean, accessible source of truth. Both humans and AI agents can review a concise set of user scenarios much faster than they can interpret thousands of lines of application and automation code. Teams already work this way with an AI skill that drafts test cases from an approved template.
Together, these cases form a knowledge base of the behavior the organization expects to preserve. They describe critical user journeys, business rules, negative paths, permissions, data states, and expected outcomes independently of how the system currently implements them. They provide a clear answer to a fundamental question after every change:

Which user scenarios must continue to work?

For this reason, every meaningful feature addition should include corresponding manual test cases. A change is not fully specified until its expected behavior can be expressed as reviewable scenarios. These cases should be validated before the implementation becomes the new baseline and before automated E2E tests are generated or updated.
This creates a growing behavioral model of the product. When a new feature is proposed, its test cases can be compared with the existing knowledge base to identify:

• Contradictions with established business rules.
• Changes to previously supported behavior.
• Overlapping or duplicate scenarios.
• Missing negative and boundary conditions.
• Effects on permissions, data integrity, and integrations.
• Regression risks across related user journeys.

Manual test cases should remain stable enough to protect expected behavior, but they must not be treated as immutable. Products evolve, requirements change, and previously valid scenarios may need to be revised or retired. The important principle is to make these changes deliberate and traceable. You need to review them separately, so implementation never introduces them as a side effect.
This is where a requirement-review agent becomes valuable. When a development agent proposes adding, modifying, or removing a manual test case, the requirement agent can compare the proposal against:

• Approved requirements and acceptance criteria.
• Existing manual test cases.
• Documented business rules.
• Backward-compatibility expectations.
• Contractual or regulatory obligations.
• Previously accepted product behavior.

The agent should determine whether the proposed test change represents a legitimate product decision, a correction to an inaccurate case, or an attempt to accommodate a regression. If a new feature breaks an existing scenario, and an approved requirement fails to replace it, you need to block the change and ask for a review. The test case stays as it is, and so does the E2E automation.
A proposed test-case change should therefore answer:

• Which requirement authorizes this change?
• Which new or modified user behavior does it describe?
• Does it alter or remove previously supported behavior?
• Which existing scenarios are affected?
• What regression risks does it introduce?
• Who must review and approve it?
• Which automated tests should be created or updated afterward?

This workflow keeps responsibilities separate. The development agent may propose behavioral changes, but it should not be able to redefine expectations silently. The requirement agent audits those changes against the product’s accumulated knowledge base. Once the manual cases are approved, a dedicated automation agent can update the E2E suite from that validated specification.
The result is a governed source of truth that is more concise than source code, more accessible than automation, and more resistant to implementation-driven test drift. Manual test cases are allowed to evolve, but only when the expected product behavior has intentionally evolved with them.

One Source of Truth Beyond Source Code

Source code is an authoritative description of what the system currently does. It is not, by itself, a sufficient description of what the system was intended to do.
In the agentic era, code is becoming cheaper to modify. That makes independent sources of intent even more important. Requirements and acceptance criteria define the expected behavior. Manual test cases that people review record the same intent and hold the source of truth. That source remains valid after implementation rewrites and framework migrations. It also holds through UI redesigns and a change of agents inside the organization.
These artifacts serve different purposes:

Treating source code as the only source of truth merges these separate questions into one artifact. That may be convenient, but it weakens independent verification.

The Business Case

Manual test cases are sometimes dismissed as expensive documentation. That assessment changes when they are considered part of an agentic control system. Well-maintained manual cases can reduce:

• Repeated E2E repair work.
• Accidental acceptance of regressions.
• Ambiguity passed between product and engineering.
• Test duplication generated by multiple agents.
• Dependence on individual test-framework expertise.
• The cost of replacing brittle automation.
• The risk of an agent validating its own misunderstanding.

They also improve traceability, once coverage and requirement links sit in one dashboard. A CTO can see which requirements are protected. A manager can understand the impact of a proposed change. A QA engineer can identify missing negative and regression coverage. An automation agent can generate checks from an approved behavioral contract. The objective is not to maximize the number of manual tests. It is to establish enough independent behavioral coverage to prevent implementation-driven test drift.

Bottom Line

Agentic development produces code faster and cheaper, including automated test code. It does not automatically make either one correct. When the same process generates an implementation and continuously adjusts its tests, a green pipeline can lose its meaning. The organization risks entering an implement-fail-fix-regression loop in which agents spend increasing amounts of time reconciling code with tests that no longer represent independently approved expectations. Manual test cases provide a stable layer of behavioral intent. Combined with requirements, acceptance criteria, independent automation, and controlled approval of behavioral changes, they create a quality system that agents can accelerate without silently redefining.
As a Testomat.io team, we provide a Test Management System, ready for agentic development. We provide a knowledge base as test cases via our MCP server, and a practical set of agent skills that establishes QA process. We believe that the importance of QA is growing in agentic times. Firing a QA team to save money for tokens is a dead-end way. What is needed today is establishing an agentic-ready QA process, which can be controlled by professional QA personnel. And that’s why it’s the right time to do actual test case management. Something that you, your QA, and your agent can tell as a source of truth. In the agentic era, test cases are not a step backward from automation. They are the contract that keeps automation sane. Take the user journey your team is most afraid to break and store it in Testomat.io as an approved case your agents read through MCP: start for free or book a demo.